In general I like the PR.

But to be honest it took some time for me to understand the abstraction behind and how we are going to use it. So let me phrase it here, to be sure we are on the same page:

We introduce an abstraction behind the chunk builder machine so we can use different encodings

We are going to use it in order to be able to keep different chunk encoding for example raw or zstd.

If so I'm ok, however I see that it seems it misses one scenario:

1. using zstd-e — because we abstract only final representation we no longer have an access to the entry data here, so can't encode entry by entry.

@qnikst

We introduce an abstraction behind the chunk builder machine so we can use different encodings

The idea is to be quite more general. Specifically, I would like to use this logic to also build metadata records, from metadata entries. I wanted to avoid duplicating much of the code for this purpose, and that's the motive for this PR. In other words, I would phrase it like:

We introduce an abstraction behind the chunk builder machine so that it can be used to build a record (chunk, metadata, ...) from a stream of abstract entries and an instance of a typeclass that defines how to build that record from those entries

Regarding

using zstd-e — because we abstract only final representation we no longer have an access to the entry data here, so can't encode entry by entry.

Hmm true, in this current implementation we lose access to custom entry encoding. We could require an entry encoding function on the BuilderItem type class for this purpose.

Regardless, I'm open to discuss this further because I feel this might be a case of "Don't Repeat Yourself" vs. "So much complexity in software comes from trying to make one thing do two things."
Personally, I always feel compelled towards the first one, but that might be an irrational decision sometimes :)

I totally agree with the current approach and extending is as complex as adding one extra method to the type class, so I'm fine with the approach